Providing customer information obtained from a carrier system to a client device

ABSTRACT

Methods and systems are presented for accessing customer relationship management (CRM) information stored in a carrier system associated with a user of an identified client device. A client device is identified based on client device identification information received from a carrier system. CRM information associated with the identified client device is received from the carrier system, and data corresponding to at least a subset of the CRM information is output to the client device. The client device may be configured to pre-populate data fields of a transaction based on the data corresponding to at least a subset of the CRM information.

The present disclosure relates to transactions made on a client device,and more particularly relates to accessing customer relationshipmanagement (CRM) information stored in a carrier system associated witha user of an identified client device.

SUMMARY

Methods and systems are provided for receiving customer relationshipmanagement (CRM) information associated with an identified client deviceand providing the information to the client device. In some embodiments,the client device may be configured to pre-populate data fieldsassociated with a transaction. Typically, transactions requireinformation, including payment information, which may be tedious anddifficult to enter on a client device, such as a mobile phone.Accordingly, an aggregator system of the present disclosure may receiveCRM information associated with a client device based on anidentification of the client device, and the CRM information may be usedto pre-populate data fields on the client device. The CRM informationmay be received from any suitable source, such as a carrier systemassociated with the client device. Thus, a consumer need not be requiredto manually complete data fields related to client device transactions.

In some embodiments, an aggregator system receives client deviceinformation from a carrier system and identifies a client device basedon the client device identification information. The aggregator systemfurther receives CRM information from the carrier system and outputsdata corresponding to at least a subset of the CRM information to theclient device based at least in part on the client device identificationinformation, where the client device is configured to pre-populate datafields based on the data corresponding to at least a subset of the CRMinformation.

In some embodiments, an aggregator method includes identifying a clientdevice based on client device identification information received from acarrier system. The aggregator method further includes receiving CRMinformation from the carrier system and outputting data corresponding toat least a subset of the CRM information to the client device based atleast in part on the client device identification information, where theclient device is configured to pre-populate data fields based on thedata corresponding to the least a subset of the CRM information.

In some embodiments, a non-transitory computer readable medium hasstored instructions that when executed direct a carrier input to receiveclient device identification information from a carrier system, anddirect client device identification circuitry to identify a clientdevice based on the client device identification information. Whenexecuted, the instructions further direct a carrier input to receive CRMinformation from the carrier system and communication circuitry tooutput data corresponding to at least a subset of the CRM information tothe client device based at least in part on the client deviceidentification information. The client device is configured topre-populate data fields based on the data corresponding to at least asubset of the CRM information.

In some embodiments, an aggregator system receives client deviceidentification information from a merchant system and identifies aclient device based on the client device identification information. Theaggregator system further receives CRM information from a carrier systemand outputs data corresponding to at least a subset of the CRMinformation to the client device based at least in part on the clientdevice identification information, where the client device is configuredto pre-populate data fields based on the data corresponding to at leasta subset of the CRM information.

In some embodiments, an aggregator method includes identifying a clientdevice based on client device identification information received from amerchant system. The aggregator method further includes receiving CRMinformation from a carrier system and outputting data corresponding toat least a subset of the CRM information to the client device based atleast in part on the client device identification information, where theclient device is configured to pre-populate data fields based on thedata corresponding to the least a subset of the CRM information.

In some embodiments, a non-transitory computer readable medium hasstored instructions that when executed direct a merchant input toreceive client device identification information from a merchant system,and direct client device identification circuitry to identify a clientdevice based on the client device identification information. Whenexecuted, the instructions further direct a carrier input to receive CRMinformation from a carrier system and communication circuitry to outputdata corresponding to at least a subset of the CRM information to theclient device based at least in part on the client device identificationinformation. The client device is configured to pre-populate data fieldsbased on the data corresponding to at least a subset of the CRMinformation.

BRIEF DESCRIPTION OF THE FIGURES

The above and other features of the present disclosure, its nature andvarious advantages will be more apparent upon consideration of thefollowing detailed description, taken in conjunction with theaccompanying drawings in which:

FIG. 1 is a block diagram of illustrative systems and devicesimplemented in a network environment in accordance with some embodimentsof the present disclosure;

FIG. 2 is a block diagram showing illustrative paths of communicationbetween systems and devices in accordance with some embodiments of thepresent disclosure;

FIG. 3 is a block diagram of an illustrative aggregator system inaccordance with some embodiments of the present disclosure;

FIG. 4 is a block diagram of an illustrative merchant system inaccordance with some embodiments of the present disclosure;

FIG. 5 is a block diagram of an illustrative carrier system inaccordance with some embodiments of the present disclosure;

FIG. 6 is a block diagram of an illustrative client device in accordancewith some embodiments of the present disclosure;

FIG. 7 is a block diagram showing an illustrative process flow in asystem that implements a mobile originated client device identificationtechnique in accordance with some embodiments of the present disclosure;

FIG. 8 is a block diagram showing an illustrative process flow in asystem that implements a mobile terminated client device identificationtechnique in accordance with some embodiments of the present disclosure;

FIG. 9 is a block diagram showing an illustrative process flow in asystem that implements a header enrichment client device identificationtechnique in accordance with some embodiments of the present disclosure;

FIG. 10 shows an illustrative client-initiated interaction between aclient device and an aggregator system in accordance with someembodiments of the present disclosure;

FIG. 11 is a flow diagram including illustrative steps for outputtingdata corresponding to at least a subset of CRM information in accordancewith some embodiments of the present disclosure;

FIG. 12 shows a sequence of illustrative displays in which data fieldsare pre-populated in accordance with some embodiments of the presentdisclosure;

FIG. 13 shows another sequence of illustrative displays in which datafields are pre-populated in accordance with some embodiments of thepresent disclosure; and

FIG. 14 is a block diagram showing detailed components of anillustrative aggregator system in accordance with some embodiments ofthe present disclosure.

DETAILED DESCRIPTION OF THE FIGURES

The present disclosure is directed towards using customer relationshipmanagement (CRM) information stored at a carrier system in connectionwith a transaction at a client device. For example, the CRM informationmay be used to pre-populate fields of a form being displayed on theclient device. The client device may be for example, a mobile phoneowned by a user having an account with the carrier system. The carriersystem provides mobile network services to the client device. In theUnited States, examples of carrier systems include systems operated byVerizon, AT&T, and Sprint, among others. CRM information, as referred toherein, is understood to refer to any suitable user-specific data,including personal information such as, for example, name, address,telephone number, email, client device location, and paymentinformation. A carrier system typically stores CRM informationassociated with its users. Attempts are made by the carrier system tokeep its stored CRM information secure because of the sensitive natureof the personal information contained therein.

In accordance with the present disclosure, a system is provided that isconfigured to access CRM information stored at the carrier system and toprovide the CRM information to a client device to be used in, forexample, a transaction between the client device and a separate merchantsystem. In some embodiments, this is accomplished by identifying theclient device, authenticating the user of the client device, andproviding the client device with the ability to make applicationprogramming interface (API) calls to the carrier system (e.g., directlyor through a conduit aggregator system trusted by the carrier system).This allows data to reach the merchant system without the need for themerchant system to communicate with the carrier system directly.

The client device may use the CRM information accessed from the carriersystem for any suitable purpose, including, for example, populatingcorresponding fields of a form to be electronically submitted to amerchant system as part of a transaction. As used herein, the term“transaction” shall be understood to include within its scope anysuitable transaction, registration, any other suitable process, or anycombination thereof. For example, a client device may use datacorresponding to at least a subset of the CRM information topre-populate data fields for a purchase transaction with a merchantsystem.

FIG. 1 is a block diagram of illustrative systems and devicesimplemented in a network environment in accordance with some embodimentsof the present disclosure. Aggregator system 100, merchant system 102,carrier system 104, and client device 106 may be coupled via network108. Network 108 may include or communicate with any suitable one ormore network structure or structures, such any suitable local areanetwork (LAN), wide area network (WAN) (e.g., the internet), wirelesslocal area network (WLAN), a mobile communications network, any othersuitable network, or any combination thereof. In some embodiments,network 108 may be a carrier network provided and operated by carriersystem 104. The lines coupling network 108 to the various systems anddevices may represent a wireless coupling, a wired coupling, any othersuitable coupling, or any combination thereof. For example, devices andsystems may be connected to network 108 through a WiFi or Ethernetconnection, with access to the internet. In another example, clientdevice 106 may be coupled to network 108 using one or more mobilecommunications networks, such as a 3G, 4G, LTE, cellular network, anyother suitable mobile communications network, or any combinationthereof.

Aggregator system 100 may be any suitable system which acts as anintermediary between two or more systems, such as between client device106 and carrier system 104, merchant system 102 and carrier system 104,client device 106 and merchant system 102, between any other systems anddevices, or any combination thereof. Aggregator system 100 may act as anintermediary by facilitating the communication of information, such aspayment information (e.g. credit card information, PayPal information,routing number data, bank account information, billing address, legalname, social security number, any other suitable information related tomaking a payment, or any combination thereof) and/or registrationinformation (e.g., name, address, email, phone number, social securitynumber, payment information, any other suitable information, or anycombination thereof), between two systems. Aggregator system 100 may betrusted by carrier system 104, and may access CRM information stored incarrier system 104 for secure communication to merchant system 102 orclient device 106. An example of aggregator system 100 is the systemdeveloped and operated by Danal Inc. (doing business as BilltoMobile)located in San Jose, Calif., which provides mobile payment services tomerchants using data provided by United States carrier systems. In someembodiments of the present disclosure, aggregator system 100 may beconfigured to provide CRM information to client device 106 or merchantsystem 102 for use in a transaction via network 108.

Merchant system 102 may be any suitable one or more entities capable ofentering into a transaction with a client device. Examples of atransaction include a purchase transaction for goods, services, or bothprovided by merchant system 102, a money transfer, a bill payment, atransaction that results in access to banking information, bankingservices, or both, any other suitable transaction, or any combinationthereof. Merchant system 102 may include, for example, a web server thatpublishes a website which requires personal information (e.g., paymentinformation, registration information). Examples of merchant system 102include systems operated by Amazon.com, Citibank, freecreditscore.com,among others. In some embodiments, merchant system 102 may be configuredto communicate with client device 106 (e.g., enable a transaction) usingnetwork 108.

Carrier system 104 may be any suitable system which provides mobilenetwork services to client device 106. Providing mobile network servicesto client device 106 may include providing a carrier network to clientdevice 106. For example, a carrier system may be a system operated byVerizon, Sprint, or AT&T.

Client device 106 is any suitable hardware, software, or both that canbe used to conduct a transaction with merchant system 102 using thecarrier network provided by carrier system 104. In some embodiments, aclient device of the present disclosure may be a mobile phone. A mobilephone may be associated with a mobile phone number, a carrier system,any other mobile phone identification information, or any combinationthereof. A client device may be a tablet device, laptop device, anyother suitable client device, mobile or otherwise, or any combinationthereof. In some embodiments, carrier system 104 may include or haveaccess to CRM information associated with client device 106, and may beconfigured to communicate the CRM information to aggregator system 100via network 108.

FIG. 2 is block diagram showing illustrative paths of communicationbetween the systems and devices of FIG. 1 in accordance with someembodiments of the present disclosure. Aggregator system 202 may beconfigured to communicate with merchant system 204, carrier system 208,and client device 206 via communications channels 210, 212, and 218respectively. Merchant system 204 may be configured to communicate withaggregator system 202 and client device 206 via communication channels210 and 218 respectively. Client device 206 may be configured tocommunicate with merchant system 204, aggregator system 202, and carriersystem 208 via communication channels 216, 218, and 214 respectively.Carrier system 208 may be configured to communicate with aggregatorsystem 202 and client device 206 via communication channels 212 and 214respectively. Communication between systems and devices may includecommunicating over a network, such as network 108 of FIG. 1, and mayinclude receiving data, sending data, or both.

FIG. 3 is a block diagram of illustrative aggregator system 300 inaccordance with some embodiments of the present disclosure. Aggregatorsystem 300 may be any suitable aggregator system, such as aggregatorsystem 100 of FIG. 1 or aggregator system 202 of FIG. 2. In someembodiments, aggregator system 300 may be implemented in a networkenvironment, such as that of FIG. 1. Aggregator system 300 may includeany suitable software, hardware, or both configured to implement thefeatures as described herein. For example, aggregator system 300 mayinclude server hardware and software. Aggregator system 300 may includecommunication circuitry 302, storage system 322, and processingequipment 320.

Communication circuitry 302 may be configured with any suitablesoftware, hardwired instructions, or both to communicate with database304 and processing equipment 320, and may include inputs, outputs, anyother mechanisms which facilitate communication with other systems anddevices, or any combination thereof. An input or output is a relativecommunication channel that can be used to receive or send data,respectively. A communication channel may be established as, forexample, an IP protocol-based communications session using any suitablenetwork infrastructure, including the Internet, any proprietary LAN,WAN, any other suitable network infrastructure, or any combinationthereof. Inputs and outputs can be implemented as one or more physicalports, a data storage device, any other suitable hardware interface,software interface, or any combination thereof. For example, aggregatorsystem 300 may include a carrier input coupled to a carrier system andconfigured to receive data from the carrier system, a carrier outputcoupled to the carrier system and configured to output data to thecarrier system, a merchant input coupled to a merchant system andconfigured to receive data from the merchant system, a merchant outputcoupled to the merchant system and configured to output data to themerchant system, a client device input coupled to a client device andconfigured to receive data from the client device, a client deviceoutput coupled to the client device and configured to output data to theclient device, any other suitable input or output, or any combinationthereof. While different inputs and outputs are described, it will beunderstood that they need not be separate components and two or more ofthe inputs and/or outputs may be implemented as a single component thatcan be used to send or receive data relative to more than onedestination or source, respectively. For example, communicationcircuitry 302 may include a transceiver, such as an Ethernet card, orany other suitable device or circuitry which facilitates communicationwith other systems and devices.

Storage system 322 may include any suitable hardware, software, or bothfor implementing an organized data storage system capable of storing oneor more databases and information related to, for example, merchantdata, client device data, user data, authentication, rules, and carrierdata. For example, storage system 322 may include database 304. In someembodiments, storage system 322 may store information which is notstored in database 304, such as information related to, for exampleapplication programming interfaces (APIs), HTML for content pages, anyother suitable information, and any combination thereof.

Database 304 may include any suitable hardware, software, or both forimplementing an organized data storage system capable of storinginformation related to, for example, merchant data, client device data,user data, and carrier data. Information related to merchant data mayinclude, for example, stock keeping units (SKUs) related to goods forsale, customer service contact information (e.g., a phone number, anemail address, a hyperlink for a website), data related to criteria forrevoking authentication, any other merchant data, or any combinationthereof. Information related to client device data may include, forexample, a mobile device number, identification information associatedwith a client device, any other client device data, or any combinationthereof. In some embodiments, database 304 may store encryptedinformation. For example, hashed information may be generated using ahash operation, and the hashed information may be stored in database304. It should be understood that aggregator system 300, or anyprocessing equipment or database thereof, such as database 304, maytemporarily store CRM information associated with a user solely for thepurpose of providing information where aggregator system 300 acts as anintermediary between systems and client devices, such that the user'sprivacy is preserved. For example, aggregator system 300 may temporarilystore CRM information associated with a user of a client device untilthe information is communicated to a merchant system, where aggregatorsystem 300 is configured to act as an intermediary between the merchantsystem and the client device. If aggregator system 300, or anyprocessing equipment or database thereof is deemed to be a trustedsystem by a carrier system that stores CRM information, and ifpermission is granted to aggregator system 300 by the carrier system,then aggregator system 300 or any processing equipment or databasethereof may be configured to store CRM information.

Processing equipment 320 may be any suitable hardware, software, or bothconfigured to process data received from other systems and devices(e.g., a client device, a merchant system, a carrier system, or anyother suitable system or device), process data to be output to othersystems and devices, generate data (e.g., generate authenticationinformation), analyze data (e.g., identify a client device based onidentification information), and perform other tasks. In someembodiments, processing equipment 320 may include one or morecircuitries for performing the functionality as described herein, suchas client device identification circuitry 306, authentication circuitry308, credential engine 310, transaction processing circuitry 312,request processing circuitry 314, data verification circuitry 316, dataintegration circuitry 318, any other suitable processing equipment, orany combination thereof. The circuitries within processing equipment 320may communicate with one another to implement the features as describedherein. Additionally, the circuitries within processing equipment 320may all be implemented together on one or more devices. In someembodiments, processing equipment 320 may communicate with communicationcircuitry 302 and database 304 to retrieve or transmit information (e.g.identification information, authentication information, any othersuitable information, or any combination thereof). For example,processing equipment 320 may send identifying information associatedwith a client device, such as a mobile phone number, to database 304 toretrieve additional information related to the client device or user inpossession of the client device.

Client device identification circuitry 306 may be configured with anysuitable software, hardwired instructions, or both to identify a clientdevice based on client device identification information. For example,client device identification circuitry 306 may be at least a portion ofone or more integrated circuit processors. Identifying a client devicemay enable aggregator system 300 to access information associated withthe client device, to communicate with the client device, toauthenticate the client device, to process a transaction on the clientdevice, to perform any other suitable action, or any combinationthereof. A client device may be identified, for example, by way of amobile originated (MO) message identification technique, a mobileterminated (MT) identification technique, a header enrichmentidentification technique, any other suitable identification technique,or any combination thereof. In some embodiments, client deviceidentification circuitry 306 may be configured to store client deviceidentification information in a database, such as database 304, and maybe configured to identify a client device based at least in part oninformation stored in database 304. Client device identificationinformation may include, for example, information identifying a mobilephone number associated with the client device, information identifyinga carrier system associated with the client device, informationidentifying software or hardware of the client device, informationidentifying a user in possession of the client device, any othersuitable identification information, or any combination thereof. Forexample, client device identification circuitry 306 may identify aclient device by identifying and storing a mobile phone numberassociated with a client device based on client device identificationinformation which is received from a carrier system.

Authentication circuitry 308 may be configured with any suitablesoftware, hardwired instructions, or both to authenticate a clientdevice. For example, authentication circuitry 308 may be at least aportion of one or more integrated circuit processors. In someembodiments, authenticating a client device may allow the client deviceto receive or request protected information (e.g., payment information),for example, as a part of a transaction. Authenticating a client devicemay include authenticating a user in possession of the client device. Insome embodiments, authenticating a user in possession of a client devicemay include verifying the identity of the user. Verifying a user'sidentity may include, for example, requesting the user to provideuniquely identifying information, requesting the user to provide aunique one-time pin, requesting the user to send a particular MOmessage, requesting the user to send a particular silent MO message,requesting the user to complete any other suitable request, or anycombination thereof. In some embodiments, authenticating a client devicemay include comparing any provided information related to a user inpossession of a client device to any information stored in database 304,for example, to detect differences between the provided information andthe information stored in database 304. In some embodiments,authentication circuitry 308 may be further configured to generate datawhich can be used to prove authentication, such as authentication keys,credential information, any other suitable information, or anycombination thereof. For example, authentication circuitry 308 may beconfigured to generate credentials for an authenticated user inpossession of a client device.

Credential engine 310 may be any suitable hardware, software, or bothconfigured to determine criteria for revoking authentication for anidentified client device. Revoking authentication for an identifiedclient device may prohibit the client device from participating ininteractions which require authentication (e.g., requesting protectedinformation for use in a transaction). In some embodiments, revokingauthentication for an identified client device may include invalidatingcredentials for an authenticated user in possession of the clientdevice. Credential engine 310 may be configured to define criteria basedon rules for revoking authentication received from a plurality ofinterested parties. Criteria may include events and conditions which,when met, indicate that authentication should be revoked. The rulesreceived from a plurality of interested parties may comprise multipletypes, and in some embodiments credential engine 310 may determinecriteria which comprise only one rule of each type. Credential engine310 may be configured to combine rules received from a plurality ofinterested parties based on a priority associated with each rules.Interested parties may be any suitable source from which informationassociated with the client device may be received (e.g. carrier systems,financial institutions, utility companies, government organizations,universities, schools, any other suitable sources, or any combinationthereof), a country in which the client device operates, any othersuitable interested party, or any combination thereof.

Transaction processing circuitry 312 may be configured with any suitablesoftware, hardwired instructions, or both to process a transaction on aclient device, such as client device 106 of FIG. 1. For example,transaction processing circuitry 312 may be at least a portion of one ormore integrated circuit processors. In some embodiments, transactionprocessing circuitry 312 may use information stored in database 304 toprocess a transaction. Processing a transaction may include, forexample, submitting payment information, completing a sale, any othersuitable process, or any combination thereof. For example, a userattempting to make a purchase transaction on a client device may beredirected from a webpage of a merchant system to a webpage associatedwith aggregator system 300, and transaction processing circuitry 312 mayprocess the purchase transaction.

Request processing circuitry 314 may be configured with any suitablesoftware, hardwired instructions, or both to process requests from othersystems and devices, such as merchant system 102 of FIG. 1, carriersystem 104 of FIG. 1, and client device 106 of FIG. 1. For example,request processing circuitry 314 may be at least a portion of one ormore integrated circuit processors. Requests may include a request tooutput information, a request to accept information, such as a rule, arequest to validate information, a request to process a transaction, anyother suitable request, or any combination thereof. In some embodiments,one or more requests may be received by communication circuitry 302, andpassed from communication circuitry 302 to request processing circuitry314. Request processing circuitry 314 may determine any suitableresponse to each of the one or more requests, such as processinginformation, retrieving information, transmitting information, any othersuitable response, or any combination thereof. In some embodiments,request processing circuitry 314 may be configured to process and/orrespond to requests received from other circuitries within processingequipment 320. For example, request processing circuitry 314 may receivea request for information associated with a client device, and may inresponse retrieve information from database 304 and communicate theinformation to communication circuitry 302 to be output.

Data verification circuitry 316 may be configured with any suitablesoftware, hardwired instructions, or both to verify informationassociated with a client device, such as client device 106 of FIG. 1.For example, data verification module 316 may be at least a portion ofone or more integrated circuit processors. In one embodiment, aggregatorsystem 300 may receive information associated with a client device fromone or more sources, and data verification circuitry 316 may beconfigured to verify the information. In another embodiment, requestprocessing circuitry 314 may receive a request from a merchant system toverify information associated with a client device, and dataverification circuitry 316 may verify the information. Verification mayinclude comparing received information to information stored in database304, comparing received information to information received from one ormore sources, deterministic matching, probabilistic matching, fuzzymatching, any other suitable verification technique, or any combinationthereof. In some embodiments, verifying information associated with aclient device may include verifying information associated with a userin possession of the client device.

Data integration circuitry 318 may be configured with any suitablesoftware, hardwired instructions, or both to integrate informationassociated with a client device which is received from one or moresources. For example, data integration circuitry 318 may be at least aportion of one or more integrated circuit processors. In one embodiment,aggregator system 300 may receive information associated with a clientdevice from one or more sources, and data integration circuitry 318 mayintegrate the data received from the one or more sources. Dataintegration may include, for example, eliminating inconsistenciesbetween information from different sources or between informationreceived from one source and information stored in a database (e.g.,database 304), eliminating duplicate information from different sourcesor between information received from one source and information storedin a database (e.g., database 304), any other suitable integrationtechnique, or any combination thereof. Sources may include interestedparties such as, for example, carrier systems, financial institutions,utility companies, government organizations, universities, schools, anyother suitable sources, or any combination thereof.

FIG. 4 is a block diagram of illustrative merchant system 400 inaccordance with some embodiments of the present disclosure. Merchantsystem 400 may be any suitable merchant system, for example, merchantsystem 102 of FIG. 1 or merchant system 204 of FIG. 2. In someembodiments, merchant system 400 may be implemented in a networkenvironment, such as that of FIG. 1. Merchant system 400 may include anysuitable software, hardware, or both configured to implement thefeatures as described herein. For example, merchant system 400 mayinclude server hardware and software. Merchant system 400 may includecommunication circuitry 402, storage system 416, and processingequipment 412.

Communication circuitry 402 may be configured with any suitablesoftware, hardwired instructions, or both to communicate with database414 and processing equipment 412, and may include inputs, outputs, anyother mechanisms which facilitate communication with other systems anddevices, or any combination thereof. An input or output is a relativecommunication channel that can be used to receive or send data,respectively. A communication channel may be established as, forexample, an IP protocol-based communications session using any suitablenetwork infrastructure, including the Internet, any proprietary LAN,WAN, any other suitable network infrastructure, or any combinationthereof. Inputs and outputs can be implemented as one or more physicalports, a data storage device, any other suitable hardware interface,software interface, or any combination thereof. For example, merchantsystem 400 may include a carrier input coupled to a carrier system andconfigured to receive data from the carrier system, a carrier outputcoupled to the carrier system and configured to output data to thecarrier system, an aggregator input coupled to an aggregator system andconfigured to receive data from the aggregator system, an aggregatoroutput coupled to the aggregator system and configured to output data tothe aggregator system, a client device input coupled to a client deviceand configured to receive data from the client device, a client deviceoutput coupled to the client device and configured to output data to theclient device, any other suitable input or output, or any combinationthereof. In the context of the present disclosure, it may bepreferential for merchant system 400 to not include a carrier input anda carrier output. That is, merchant system 400 need not be able tocommunicate with a carrier system in preferred embodiments of thepresent invention. While different inputs and outputs are described, itwill be understood that they need not be separate components and two ormore of the inputs and/or outputs may, indeed be implemented as a singlecomponent that can be used to send or receive data relative to more thanone destination or source, respectively. For example, communicationcircuitry 402 may include a transceiver, such as an Ethernet card, orany other suitable device or circuitry which facilitates communicationwith other systems and devices.

Storage system 416 may include any suitable hardware, software, or bothfor implementing an organized data storage system capable of storing oneor more databases and information related to, for example, merchantdata, client device data, user data, authentication, rules, and carrierdata. For example, storage system 416 may include database 414. In someembodiments, storage system 416 may store information which is notstored in database 414, such as information related to merchant data,for example APIs, HTML for content pages, any other suitableinformation, and any combination thereof. In some embodiments, merchantsystem 400 may be configured to communicate any information stored instorage system 416 or in database 414 to a trusted aggregator system,such as aggregator system 300.

Database 414 may include any suitable hardware, software, or both forimplementing an organized data storage system capable of storinginformation related to, for example, merchant data, client device data,user data, and carrier data. Information related to merchant data mayinclude, for example, SKUs related to goods for sale, customer servicecontact information (e.g., a phone number, an email address, a hyperlinkfor a website), payload information, data related to criteria forrevoking authentication, any other merchant data, or any combinationthereof. Information related to client device data may include, forexample, a mobile device number, identification information associatedwith a client device, any other client device data, or any combinationthereof. Information related to user data may include, for example,authentication information for an authenticated user, credentialinformation for an authenticated user, any other user relatedinformation, or any combination thereof. Carrier data may include, forexample, the carrier network associated with a client device. In someembodiments, database 414 may store information in an encrypted form.For example, hashed information may be generated using a hash operation,and the hashed information may be stored in database 414.

Processing equipment 412 may be any suitable hardware, software, or bothconfigured to process data received from other systems and devices(e.g., a client device, an aggregator system, or any other suitablesystem or device), process data to be output to other systems anddevices, generate data, analyze data (e.g., confirm authenticationinformation provided by a client device), and perform other tasks. Insome embodiments, processing equipment 412 may include one or morecircuitries for performing the functionality as described herein, suchas payload generation circuitry 404, encryption circuitry 406, requestprocessing circuitry 408, transaction processing circuitry 410, anyother suitable processing equipment, or any combination thereof. Thecircuitries within processing equipment 412 may communicate with oneanother to implement the features described herein. Additionally, thecircuitries within processing equipment 412 may all be implementedtogether on one or more devices. Processing equipment 412 maycommunicate with communication circuitry 402 and database 414 toretrieve and/or transmit information. For example, processing equipment412 may retrieve credential information associated with a user inpossession of a client device from database 414 before allowing atransaction to be made on the client device.

Payload generation circuitry 404 may be configured with any suitablesoftware, hardwired instructions, or both to generate a payload. Forexample, payload generation circuitry 404 may be at least a portion ofone or more integrated circuit processors. A payload is data whichallows a client device to initiate communication (e.g., through APIcalls) with an aggregator system. A payload may be generated by payloadgeneration circuitry 404, subsequently passed to encryption circuitry406 to be encrypted, and the encrypted payload may be passed to a clientdevice, such as client device 106 of FIG. 1. In some embodiments, apayload may be generated by combining correlation identificationinformation, a timestamp value, and a nonce value. Correlationidentification information may include, for example, merchant generatedidentification information which is associated with a particular clientdevice transaction. In some embodiments, correlation identificationinformation may be a user identification value (e.g. a user ID)associated with a user in possession of a client device. A timestampvalue may include, for example the current date and time. In someembodiments, a timestamp value may be expressed in the format“yyyyMMddHHmmss”, where “yyyy” represents the current year, “MM”represents the current month, “dd” represents the current day, “HH”represents the hours, “mm” represents the current minutes, and “ss”represents the current seconds. The timestamp value need not beexpressed in the above described format, but may instead be expressed inany suitable format. In some embodiments, a nonce value may include, forexample, a random value with a minimum length of 32 characters.

Encryption circuitry 406 may be configured with any suitable software,hardwired instructions, or both to encrypt, decrypt, or both informationsuch as, for example, a payload, information to be stored in database414, any other suitable information, or any combination thereof. Forexample, encryption module 406 may be at least a portion of one or moreintegrated circuit processors. Encrypting information may protect theinformation from being stolen, hacked, or otherwise leaked to a sourcewhich does not have permission to access the information. In someembodiments, information may be encrypted using an encryption key, suchas a symmetric key, an asymmetric key, any other suitable encryptionmethod, or any combination thereof. For example, an aggregator systemmay provision a merchant system with an encryption key, and the merchantsystem may use the encryption key to encrypt information. In someembodiments, the advanced encryption standard (AES), or any othersuitable strong symmetric-key block cipher, should be used wheninformation is encrypted by encryption circuitry 406. In someembodiments, information to be encrypted may include a payload generatedby payload generation circuitry 404. Merchant system 400 may pass apayload encrypted by encryption circuitry 406 to a client device, andthe encrypted payload may facilitate client-initiated interactionbetween a client device and an aggregator system. An encrypted payloadmay be unique for a client device, but not unique for each request madeby the client device.

Request processing circuitry 408 may be configured with any suitablesoftware, hardwired instructions, or both to process requests from othersystems and devices, for example, carrier system 104 of FIG. 1,aggregator system 100 of FIG. 1, or client device 106 of FIG. 1. Forexample, request processing circuitry 408 may be at least a portion ofone or more integrated circuit processors. Requests may include arequest to output information (e.g., identification information orauthentication information), a request to accept information, any othersuitable request, or any combination thereof. In some embodiments, oneor more requests may be received by communication circuitry 402 andpassed from communication circuitry 402 to request processing circuitry408. Request processing circuitry 408 may determine an appropriateresponse to each of the one or more requests, for example, processinginformation, generating information, analyzing information,communicating with another circuitry within processing equipment 412,transmitting data to database 414, receiving data from database 414, anyother appropriate response, or any combination thereof. In someembodiments, request processing circuitry may process, respond to, orboth, requests received from other circuitries within processingequipment 412.

Transaction processing circuitry 410 may be configured with any suitablesoftware, hardwired instructions, or both to process a transaction madeon a client device. For example, transaction processing circuitry 410may be at least a portion of one or more integrated circuit processors.Processing a transaction may include, for example, submitting paymentinformation, completing a sale, any other suitable process, or anycombination thereof. A transaction may be a purchase transaction, aregistration, any other suitable process, or any combination thereof. Insome embodiments, transaction processing circuitry 410 may use datastored in database 414 to process a transaction. In other embodiments,transaction processing circuitry 410 may use data received from anothersystem, such as an aggregator system, to process a transaction. Forexample, a client device may visit a website published by merchantsystem 400 to make a purchase transaction, and merchant system 400 mayreceive information from an aggregator system, such as aggregator system100 of FIG. 1, to process the purchase transaction. In some embodiments,transaction processing circuitry 410 may pre-populate transaction datafields with information received from another system or device, orinformation received from database 414.

FIG. 5 is a block diagram of illustrative carrier system 500 inaccordance with some embodiments of the present disclosure. Carriersystem 500 may be any suitable carrier system, such as carrier system208 of FIG. 2 or carrier system 104 of FIG. 1. In some embodiments,carrier system 500 may be implemented in a network environment, such asthat of FIG. 1. Carrier system 500 may include any suitable software,hardware, or both configured to implement the features as describedherein. For example, carrier system 500 may include server hardware andsoftware. Carrier system 500 may include communication circuitry 502,storage system 518, and processing equipment 516.

Communication circuitry 502 may be configured with any suitablesoftware, hardwired instructions, or both to communicate with database514 and processing equipment 516, and may include inputs, outputs, anyother mechanisms which facilitate communication with other systems anddevices, or any combination thereof. An input or output is a relativecommunication channel that can be used to receive or send data,respectively. A communication channel may be established as, forexample, an IP protocol-based communications session using any suitablenetwork infrastructure, including the Internet, any proprietary LAN,WAN, any other suitable network infrastructure, or any combinationthereof. Inputs and outputs can be implemented as one or more physicalports, a data storage device, any other suitable hardware interface,software interface, or any combination thereof. For example, carriersystem 500 may include an aggregator input coupled to an aggregatorsystem and configured to receive data from the aggregator system, anaggregator output coupled to the aggregator system and configured tooutput data to the aggregator system, a merchant input coupled to amerchant system and configured to receive data from the merchant system,a merchant output coupled to the merchant system and configured tooutput data to the merchant system, a client device input coupled to aclient device and configured to receive data from the client device, aclient device output coupled to the client device and configured tooutput data to the client device, any other suitable input or output, orany combination thereof. In the context of the present disclosure, itmay be preferential for carrier system 500 to not include a merchantsystem input and a merchant system output. That is, carrier system 500need not be able to communicate with a merchant system in preferredembodiments of the present invention. While different inputs and outputsare described, it will be understood that they need not be separatecomponents and two or more of the inputs and/or outputs may, indeed beimplemented as a single component that can be used to send or receivedata relative to more than one destination or source, respectively. Forexample, communication circuitry 502 may include a transceiver, such asan Ethernet card, or any other suitable device or circuitry whichfacilitates communication with other systems and devices.

Storage system 518 may include any suitable hardware, software, or bothfor implementing an organized data storage system capable of storing oneor more databases and information related to, for example, account data,rules, and CRM information associated with a user in possession of aclient device. For example, storage system 518 may include database 514.In some embodiments, storage system 518 may store information which isnot stored in database 514, and carrier system 500 may be configured tocommunicate such information to a trusted aggregator system, such asaggregator system 300.

Database 514 may include any suitable hardware, software, or both forimplementing an organized data storage system capable of storinginformation related to, for example, account data and CRM informationassociated with a user in possession of a client device. In someembodiments, database 514 may store information in an encrypted form.For example, hashed information may be generated using a hash operation,and the hashed information may be stored in database 514.

Processing equipment 516 may be any suitable hardware, software, or bothconfigured to process data received from other systems and devices(e.g., a client device, an aggregator system, or any other suitablesystem or device), process data to be output to other systems anddevices (e.g., CRM information), and perform other tasks. In someembodiments, processing equipment 516 may include one or morecircuitries for performing the functionality as described herein, suchas header enrichment circuitry 504, message creation circuitry 506,redirect circuitry 508, request processing circuitry 510, CRMinformation retrieval circuitry 512, any other suitable processingequipment, or any combination thereof. The circuitries within processingequipment 516 may communicate with one another to implement the featuresas described herein. Additionally, the circuitries within processingequipment 516 may all be implemented together on one or more devices.Processing equipment 516 may be configured to communicate withcommunication circuitry 502 and database 514 to retrieve and/or transmitinformation related to user account data, CRM information, any otherinformation, or any combination thereof.

Header enrichment circuitry 504 may be configured with any suitablesoftware, hardwired instructions, or both to insert one or more headers(e.g., a hypertext transfer protocol (http) header) into a request orresponse, such as an http redirect request or response. For example,header enrichment circuitry 504 may be at least a portion of one or moreintegrated circuit processors. An http redirect request and/or responsemay include a message header, and an http header may be inserted intothe message header. In some embodiments, http headers inserted into anhttp redirect request may include client device identificationinformation, and a system receiving an http response where http headerswere inserted in a corresponding http request may extract the clientdevice identification information for use or storage (e.g., for use inidentifying a client device). For example, a client device on a carriernetwork operated by carrier system 500 may be redirected from a websitepublished by a merchant system to a website published by an aggregatorsystem using an http redirect request processed by carrier system 500,and header enrichment circuitry 504 may insert one or more http headersin the http redirect request.

Message creation circuitry 506 may be configured with any suitablesoftware, hardwired instructions, or both to create a message such as,for example, a short message service (SMS) message, a silent SMSmessage, any other suitable type of message, or any combination thereof.For example, message creation circuitry 506 may be at least a portion ofone or more integrated circuit processors. In some embodiments, messagecreation circuitry 506 may be configured to generate an SMS message inresponse to a request from another system or device, such as aggregatorsystem 100 of FIG. 1 or client device 106 of FIG. 1. For example,carrier system 500 may receive a request to generate an SMS message andsend it to a client device, and message creation circuitry may createthe SMS message and may specify that the message should be sent to themobile phone number of the client device.

Redirect circuitry 508 may be configured with any suitable software,hardwired instructions, or both to redirect, for example, a request,information, or both from one system to another system. For example,redirect circuitry 508 may be at least a portion of one or moreintegrated circuit processors. In some embodiments, redirect circuitry508 may be configured to redirect an SMS message from one system ordevice to another system or device. In other embodiments, redirectcircuitry 508 may be configured to perform an http redirect from awebsite associated with one system to a website associated with anothersystem. Redirect circuitry 508 may additionally be configured to performany other suitable redirect from one system to another system. In someembodiments, redirect circuitry 508 may receive instructions which causethe redirect to be performed. In some embodiments, redirect circuitry508 may receive such instructions from request processing circuitry 410.

Request processing circuitry 510 may be configured with any suitablesoftware, hardwired instructions, or both to process requests from othersystems and devices, for example, aggregator system 100 of FIG. 1 orclient device 106 of FIG. 1. For example, request processing circuitry510 may be at least a portion of one or more integrated circuitprocessors. Requests may include a request for information, such as useraccount information or CRM information, any other suitable request, orany combination thereof. One or more requests may be received bycommunication circuitry 502 and passed from communication circuitry 502to request processing circuitry 510. Request processing circuitry 510may determine a suitable response to each of the one or more requests,such as processing information, communicating with another circuitrywithin processing equipment 516, transmitting data to database 514,receiving data from database 514, any other appropriate response, or anycombination thereof. In some embodiments, request processing circuitry510 may process, respond, or both to requests received from othercircuitries within processing equipment 516.

CRM information retrieval circuitry 512 may be configured with anysuitable software, hardwired instructions, or both to retrieve CRMinformation associated with a client device. For example, CRMinformation retrieval circuitry 512 may be at least a portion of one ormore integrated circuit processors. In some embodiments, CRM informationmay include information related to an account associated with a user inpossession of a client device (e.g., payment information, name, address,social security number, etc.), or any other suitable information whichmay be obtained through interactions between carrier system 500 and aclient device. It should be understood that protected informationassociated with a user, such as a social security number, may only beaccessed by trusted systems and devices to which permission has beengranted by the user. CRM information retrieval circuitry 512 may beconfigured to retrieve appropriate CRM information from database 514. Insome embodiments, CRM information retrieval circuitry 512 may beconfigured to retrieve appropriate CRM information in response to arequest received from request processing circuitry 510. For example, anaggregator system, such as aggregator system 100 of FIG. 1, may requestCRM information associated with an identified client device from carriersystem 500, and CRM information retrieval circuitry 512 may retrieve therequested CRM information and provide it to communication circuitry 502to be output to the aggregator system.

FIG. 6 is a block diagram of illustrative client device 600 inaccordance with some embodiments of the present disclosure. Clientdevice 600 may be any suitable client device, such as client device 206of FIG. 2 or client device 106 of FIG. 1. In some embodiments clientdevice 600 may be implemented in a network environment, such as that ofFIG. 1. Client device 600 may include any suitable software, hardware,or both configured to implement the features as described herein. Clientdevice 600 may include display 602, communication circuitry 616, powersupply 622, speaker 610, microphone 612, keyboard 614, memory 608, andprocessing equipment 620.

Display 602 may be configured to display any information stored on orreceived by client device 600 in any suitable format. Informationdisplayed may include, for example, information requested by a user ofclient device 600, information related to client device 600, informationrelated to a transaction, information related to an mobile application,information received from another system or device, information to besent to another system or device, an SMS message, any other suitableinformation, or any combination thereof. Display 602 may be, forexample, a flat panel display such as a liquid crystal display, plasmadisplay, any other suitable display, or any combination thereof.

Power supply 622 may be configured to supply power to client device 600.Power supply 622 may be any suitable internal or external power sourcesuch as, for example, a battery.

Speaker 610 may be configured to provide audible sound. The audiblesound may be related to a phone call on client device 600, anapplication running on client device 600, an alarm set on client device600, a transaction, any other suitable process or application, or anycombination thereof.

Microphone 612 may be configured to receive user input such as, forexample, audible user input. The inputs received by microphone 612 mayinclude information related to, for example, a phone call on clientdevice 600, a user in possession of client device 600, a transaction,any other suitable information, or any combination thereof.

Keyboard 614 may be configured to receive user input such as, forexample, text input. The inputs received by keyboard 614 may beinformation related to, for example, a message stored on or created onclient device 600, a user in possession of client device 600, atransaction, any other suitable information, or any combination thereof.

Communication circuitry 616 may include inputs, outputs, any othermechanisms which facilitate communication with other systems anddevices, or any combination thereof. Communication circuitry 616 may beconfigured with any suitable software, hardwired instructions, or both.An input or output is a relative communication channel that can be usedto receive or send data, respectively. A communication channel may beestablished as, for example, an IP protocol-based communications sessionusing any suitable network infrastructure, including the Internet, anyproprietary LAN, WAN, any other suitable network infrastructure, or anycombination thereof. Inputs and outputs can be implemented as one ormore physical ports, a data storage device, any other suitable hardwareinterface, software interface, or any combination thereof. For example,client device 600 may include a carrier input coupled to a carriersystem and configured to receive data from the carrier system, a carrieroutput coupled to the carrier system and configured to output data tothe carrier system, a merchant input coupled to a merchant system andconfigured to receive data from the merchant system, a merchant outputcoupled to the merchant system and configured to output data to themerchant system, an aggregator input coupled to an aggregator system andconfigured to receive data from the aggregator system, an aggregatoroutput coupled to the aggregator system and configured to output data tothe aggregator system, any other suitable input or output, or anycombination thereof. While different inputs and outputs are described,it will be understood that they need not be separate components and twoor more of the inputs and/or outputs may, indeed be implemented as asingle component that can be used to send or receive data relative tomore than one destination or source, respectively. For example,communication circuitry 616 may include a transceiver, such as anEthernet card, or any other suitable device or circuitry whichfacilitates communication with other systems and devices. Communicationcircuitry 616 may be configured to communicate with memory 608,processing equipment 620, speaker 610, microphone 612, keyboard 614,power supply 622, and display 602.

Memory 608 may be one or more suitable memory devices such as, forexample, a hard disk drive, flash memory, random access memory (RAM), anoptical disk, any other suitable memory device, or any combinationthereof. Memory 608 may include identification information 604 and otherinformation 606. Identification information 604 may include any suitableidentification information related to client device 600. For example,identification information 604 may include information identifyinghardware or software of client device 600, information identifying amobile phone number associated with client device 600, informationidentifying a device model of client device 600, information identifyinga user in possession of client device 600, information identifying acarrier system associated with client device 600, any other suitableidentification information, or any combination thereof. Otherinformation 606 may include any information stored in memory 608 otherthan identification information 604. For example, other information 606may store information related to applications, messaging, photos andvideos, transactions, merchants, networks, capacity and storage, anyother suitable information, or any combination thereof.

Processing equipment 620 may be any suitable hardware, software, or bothconfigured to process data received from other systems and devices(e.g., a merchant system, a carrier system, an aggregator system, or anyother suitable system or device), process data to be output to othersystems and devices, process data related to mobile applications, andperform other tasks. In some embodiments, processing equipment 620 mayinclude one or more circuitries for performing the functionality asdescribed herein, such as authentication circuitry 616, processingcircuitry 618, any other suitable processing equipment, or anycombination thereof. The circuitries within processing equipment 620 maycommunicate with one another to implement the features as describedherein. Additionally, the circuitries within processing equipment 620may all be implemented together on one or more devices. Processingequipment 620 may be configured to communicate with communicationcircuitry 616, memory 608, speaker 610, microphone 612, keyboard 614,power supply 622, and display 602.

Authentication circuitry 616 may be configured with any suitablesoftware, hardwired instructions, or both to authenticate client device600. For example, authentication circuitry 616 may be at least a portionof one or more integrated circuit processors. In some embodiments,authenticating client device 600 may include authenticating a user inpossession of client device 600. In some embodiments, authenticationcircuitry 616 may communicate with a system, such as a merchant systemor an aggregator system, via communication circuitry 616, in order toauthenticate client device 600. Authenticating client device 600 mayinclude prompting a user in possession of client device 600 to inputinformation. Information may be input via display 602, keyboard 614,microphone 612, any other suitable user input, or any combinationthereof. Information may include, for example, uniquely identifyinginformation related to the user in possession of client device 600. Insome embodiments, authentication circuitry 616 may communicate withmemory 608 to authenticate client device 600. For example, memory 608may store information received from an aggregator system, such asaggregator system 100 of FIG. 1, and subsequent to prompting a user inpossession of client device 600 for information, authenticationcircuitry 616 may compare the entered information to that stored inmemory 608.

Processing circuitry 618 may be configured with any suitable software,hardwired instructions, or both to implement any features other thanauthentication. For example, processing circuitry 618 may be at least aportion of one or more integrated circuit processors. For example,processing circuitry 618 may be configured to run applications, tocompute information, to process instructions, to carry out functionsrelated to client device operation, to carry out any other suitableoperation or implementation, or any combination thereof.

FIG. 11 is a flow diagram including illustrative steps for outputtingdata corresponding to at least a subset of CRM information in accordancewith some embodiments of the present disclosure. In some embodiments,the steps of FIG. 11 may be performed by an aggregator system, such asaggregator system 100 of FIG. 1, aggregator system 202 of FIG. 2, oraggregator system 300 of FIG. 3.

At step 1102, client device identification information is received by anaggregator system. In some embodiments, client device identificationinformation (e.g., information identifying a mobile phone numberassociated with the client device, information identifying a carriersystem associated with the client device, information identifyingsoftware or hardware of the client device, information identifying auser in possession of the client device, any other suitableidentification information, or any combination thereof) may be receivedfrom a carrier system. In other embodiments, client deviceidentification information may be received from a merchant system. Insome embodiments, an input may be used to receive the client deviceidentification information. For example, communication circuitry 302 ofFIG. 3 may be used to receive the client device identificationinformation.

At step 1104, a client device may be identified by the aggregator systembased on the client device identification information received at step1102. The client device may be identified by processing equipment, suchas client device identification circuitry 306 of FIG. 3. In someembodiments, a client device may be identified using an MOidentification technique, an MT identification technique, a headerenrichment identification technique, any other suitable identificationtechnique, or any combination thereof.

FIG. 7 is a block diagram showing an illustrative process flow in asystem that implements a MO message client device identificationtechnique in accordance with some embodiments of the present disclosure.In the MO message identification technique, merchant system 702 mayrequest the user of client device 704 to send an SMS message to aspecified short code via communication path 708. In response to therequest received from merchant system 702, the user of client device 704may send an SMS message to the specified short code via communicationpath 710. Carrier system 706 may route the SMS message sent by clientdevice 704, along with client device identification informationincluding the user's mobile phone number, to aggregator system 700.Aggregator system 700 may receive the SMS message and client deviceidentification information routed by carrier system 706, andsubsequently may identify the client device at 714. Identifying theclient device may include storing the received client deviceidentification information, including the user's mobile phone number, ina database of aggregator system 700, such as database 304. Merchantsystem 702 may be any suitable merchant system, such as merchant system400 of FIG. 4, merchant system 204 of FIG. 2, or merchant system 102 ofFIG. 1. Client device 704 may be any suitable client device, such asclient device 600 of FIG. 6, client device 206 of FIG. 2, or clientdevice 106 of FIG. 1. Carrier system 706 may be any suitable carriersystem, such as carrier system 500 of FIG. 5, carrier system 208 of FIG.2, or carrier system 104 of FIG. 1. Aggregator system 700 may be anysuitable aggregator system, such as aggregator system 300 of FIG. 3,aggregator system 202 of FIG. 2, or aggregator system 100 of FIG. 1.

In other embodiments, a client device may be identified at step 1104using an MT message identification technique, as shown in FIG. 8. In theMT message client device identification technique shown in FIG. 8,merchant system 802 provides aggregator system 800 with the mobile phonenumber of the user of client device 804, and requests aggregator system800 to send a unique PIN to client device 804. Merchant system 802 mayprovide the mobile phone number and make the request to aggregatorsystem 800 via communication path 808. In response to the request frommerchant system 802, aggregator system 800 may generate a unique PIN at810. Aggregator system 800 sends an SMS message identifying the uniquePIN which is routed to carrier system 806 via communication path 812,and routed from carrier system 806 to client device 804 viacommunication path 814. Subsequent to receiving the SMS message withunique PIN, client device 804 communicates the unique PIN to merchantsystem 802 via communication path 816. Merchant system 802 then requestsaggregator system 800 to validate the unique PIN communicated by clientdevice 804 via communication path 818. Aggregator system 800 mayvalidate the unique PIN by comparing the unique PIN communicated byclient device 804 against the unique PIN generated at step 810. Ifaggregator system 800 determines that the unique PIN entered by clientdevice 804 matches the unique PIN generated at step 810, thenidentification is successful. Merchant system 802 may be any suitablemerchant system, such as merchant system 400 of FIG. 4, merchant system204 of FIG. 2, or merchant system 102 of FIG. 1. Client device 804 maybe any suitable client device, such as client device 600 of FIG. 6,client device 206 of FIG. 2, or client device 106 of FIG. 1. Carriersystem 806 may be any suitable carrier system, such as carrier system500 of FIG. 5, carrier system 208 of FIG. 2, or carrier system 104 ofFIG. 1. Aggregator system 800 may be any suitable aggregator system,such as aggregator system 300 of FIG. 3, aggregator system 202 of FIG.2, or aggregator system 100 of FIG. 1.

In other embodiments, a client device may be identified at step 1104using a header enrichment identification technique, as shown in FIG. 9.In the header enrichment client device identification technique shown inFIG. 9, client device 904 communicates with merchant system 902 andcarrier system 906 via a carrier network. Upon initiating communicationwith merchant system 902, client device 904 is redirected to aggregatorsystem 900 via carrier system 906. Client device 904 may initiatecommunication with merchant system 902, for example, by accessing awebpage associated with merchant system 902. Merchant system 902 sendsthe redirect request via communication path 908, and the client deviceis redirected by carrier system 906 to aggregator system 900 viacommunication paths 910 and 912. Carrier system 906 inserts headers inthe redirect request, and aggregator system 900 identifies client device904 at 914 based on client device identification information extractedfrom the headers. In some embodiments, aggregator system 900 may need todecrypt information in the headers before client device 904 can beidentified. In other embodiments, aggregator system 900 may need torequest additional information from carrier system 906 before clientdevice 904 can be identified. Merchant system 902 may subsequentlyrequest identification information associated client device 904 fromaggregator system 900 via communication path 916. In response to therequest received from merchant system 902 via communication path 916,aggregator system 900 may redirect client device 904 back to merchantsystem 902 and return the requested identification information viacommunication path 918. Merchant system 902 may be any suitable merchantsystem, such as merchant system 400 of FIG. 4, merchant system 204 ofFIG. 2, or merchant system 102 of FIG. 1. Client device 904 may be anysuitable client device such as client device 600 of FIG. 6, clientdevice 206 of FIG. 2, or client device 106 of FIG. 1. Carrier system 906may be any suitable carrier system such as carrier system 500 of FIG. 5,carrier system 208 of FIG. 2, or carrier system 104 of FIG. 1.Aggregator system 900 may be any suitable aggregator system such asaggregator system 300 of FIG. 3, aggregator system 202 of FIG. 2, oraggregator system 100 of FIG. 1.

At step 1106 of FIG. 11, a user in possession of the identified clientdevice may be authenticated by the aggregator system. In someembodiments, processing equipment such as authentication circuitry 308may be used to authenticate the client device at step 1106. In someembodiments, authenticating a user may include verifying the identity ofthe user. Verifying a user may include, for example, requesting uniquelyidentifying information from the user, requesting the user to confirm aunique PIN sent to the user's client device, requesting the user to senda specific MO message, requesting the user to send a specific silent MOmessage, any other suitable verification technique or request, or anycombination thereof. Authenticating a user may additionally includecomparing any information provided by the user in possession of theclient device to any information stored in a database of the aggregatorsystem, such as database 304, determining that the client device has notbeen identified as being stolen, determining that the client device hasnot been associated with a fraud event, any other suitable process oranalysis, or any combination thereof.

At step 1108, the aggregator system may determine whether or not theuser in possession of the client device has been authenticated. If atstep 1108 the aggregator system determines that the user of the clientdevice has not been authenticated, step 1106 will be repeated and theaggregator system will attempt to authenticate the user in possession ofthe client device again. In some embodiments, authentication may only beattempted a limited number of times, for example, three times. If atstep 1108 the aggregator system determines that the user in possessionof the client device has been authenticated, the aggregator system mayproceed to step 1110.

At step 1110, the aggregator system may determine whether or not userconsent has been received. User consent may be provided by the user inpossession of the client device, and may be requested by the aggregatorsystem or a merchant system. User consent may indicate permission forthe aggregator system to retrieve protected consumer and paymentinformation, such as CRM information. For example, the aggregator systemmay send the client device a message requesting permission to retrieveprotected information (e.g., CRM information), and in response the userin possession of the client device may reply with or select anindication which grants or denies permission. User consent may berequested and/or received by the aggregator system using inputs and/oroutputs, such as communication circuitry 302 of FIG. 3. If at step 1110the aggregator system determines that user consent has been received,the aggregator system may proceed to step 1112.

At step 1112, the aggregator system may receive CRM informationassociated with the identified client device. In some embodiments, theCRM information may be associated with a user in possession of theclient device, and may include information such as payment information,registration information, any other suitable information, protected ornot, or any combination thereof. The CRM information may be receivedfrom a carrier system, such as carrier system 104 of FIG. 1, and may bebased on transactions between the carrier system and the user of theclient device. The CRM information need not be received from a carriersystem, and may be received from any other suitable source such asfinancial institutions, utility companies, government organizations,universities, schools, any other suitable sources, or any combinationthereof. The CRM information may be received using an input, such as,for example, communication circuitry 302 of FIG. 3.

At step 1114, the aggregator system may output data corresponding to atleast a subset of the CRM information. Data corresponding to at least asubset of the CRM information may be output using, for example,communication circuitry 302 of FIG. 3. In some embodiments, datacorresponding to at least a subset of the CRM information may include auser's first and last name, credit card or bank account information,address, and email information. In some embodiments, the data may beoutput to a client device for use in a transaction. In otherembodiments, the data may be output to a merchant for use in atransaction. The client device or a merchant system may be configured topre-populate data fields based on the CRM information, as shown in FIG.12 and FIG. 13.

FIG. 12 shows a sequence of illustrative displays in which data fieldsare pre-populated in accordance with some embodiments of the presentdisclosure. Display 1200 shows blank registration data fields 1206 for aregistration being made on a client device, such as client device 106 ofFIG. 1. The registration may be, for example, a registration for awebsite published by a merchant, a club, an organization, a financialinstitution, any other suitable entity requiring registration, or anycombination thereof. Subsequent to receiving data from an aggregatorsystem, such as data corresponding to at least a subset of CRMinformation associated with the client device, the client device maypre-populate the data fields as shown in display 1202. Transitionalarrow 1208 may represent the client device pre-populating the datafields 1206. A client device may re-populate fields using processingequipment, such as processing circuitry 618 of FIG. 6. Display 1202illustrates registration data fields 1210, which are completed withpre-populated information associated with the user in possession of theclient device. Display 1204 illustrates a confirmation screen on whichthe user may confirm the accuracy of the information 1214 which was usedto pre-populate data fields 1206 on the client device. Displays 1200,1202, and 1204 all may be display screens of a client device, such asclient device 106 of FIG. 1, client device 206 of FIG. 2, or clientdevice 600 of FIG. 6.

FIG. 13 shows another sequence of illustrative displays in which datafields are pre-populated in accordance with some embodiments of thepresent disclosure. Display 1300 illustrates transaction details,including purchase information, for a transaction being made on a clientdevice, such as client device 106 of FIG. 1. The transaction may be, forexample, a transaction for a sale of goods or services on a websitepublished by a merchant system, a transaction to pay a bill, any othersuitable transaction requiring payment information, or any combinationthereof. Subsequent to receiving data corresponding to at least a subsetof CRM information associated with the user in possession of the clientdevice (e.g., from an aggregator system or another suitable system), theclient device may pre-populate data fields for the transaction withinformation, including payment information, at 1304. Display 1302illustrates a confirmation screen on which the user of the client devicemay confirm the information, including payment information, which wasused to pre-populate the transaction data fields at 1304. Displays 1300and 1302 may be display screens of a client device, such as clientdevice 106 of FIG. 1, client device 206 of FIG. 2, or client device 600of FIG. 6.

FIG. 10 shows an illustrative client-initiated interaction between aclient device and an aggregator system in accordance with someembodiments of the present disclosure. In some embodiments, merchantsystem 1002 may provide client device 1004 with one or more JavaScriptimports 1006 and an encrypted payload, such that client device 1004 maydirectly communicate with aggregator system 1000. JavaScript imports1006 provided by merchant system 1002 may include a JQuery JavaScriptimport, an aggregator JavaScript API, any other suitable JavaScriptimports, or any combination thereof. An encrypted payload may begenerated by merchant system 1002 at 1008 using processing equipmentsuch as, for example, payload generation circuitry 404 of FIG. 4 andencryption circuitry 406 of FIG. 4. Merchant system 1002 may pass theencrypted payload to client device 1004 via communication path 1010. Insome embodiments, client device 1004 may perform a transaction byinitiating an interaction with aggregator system 1000 using JavaScriptimports 1006 and via communication path 1012.

In some embodiments, client device 1004 may make an identification APIcall to aggregate system 1000 using JavaScript imports 1006. Anidentification API call made by client device 1004 may include a requestobject, a success handler, an error handler, any other suitableparameter, or any combination thereof. A request object provided byclient device 1004 may include a method name, hashed merchantidentification information, the encrypted payload, any additional methodspecific parameters, or any combination thereof. A method name mayspecify, for example, an identification method, a method to retrieveinformation related to a user of client device 1004, any other suitablemethod, or any combination thereof. Hashed merchant identificationinformation may be provided to client device 1004 by merchant system1002. Merchant system 1002 may generate hashed merchant identificationinformation by performing a hash operation on merchant identificationinformation provided by aggregator system 1000. A success handler, whenactivated, may allow the transaction being performed on client device1004 to continue. An error handler, when activated, may cause thetransaction being performed on client device 1004 to halt. A successfulidentification call may identify the user of client device 1004 withaggregate system 1000, and may return information related to the carriersystem associated with client device 1004 to be used on subsequent APIcalls via communication path 1012.

In some embodiments, client device 1004 may make an API call requestinginformation to aggregate system 1000 using JavaScript imports 1006.Requested information may include, for example, CRM information, or anyother information including protected information. An API callrequesting information made by client device 1004 may include a requestobject, a success handler, an error handler, and pre-populatingparameter. The request object, success handler, and error handler for anAPI call requesting information are the same as the request object,success handler, and error handler for an identification call asdescribed above. A pre-populating parameter may be have a value of trueor false, and may indicate whether client device 1004 shouldpre-populate data fields in the transaction being performed on clientdevice 1004 upon receiving the requested information. A successfulrequest for information call may return the requested information fromaggregator system 1000 to client device 1004 along communication path1012. In some embodiments, client device 1004 may request information tocomplete a transaction, and may be configured to pre-populate datafields of the transaction with information returned by aggregator system1000. It should be understood that client device 1004 may make variousother API calls to aggregator system 1000, and is not limited to makingidentification calls and request for information calls. Merchant system1002 may be any suitable merchant system, such as merchant system 400 ofFIG. 4, merchant system 204 of FIG. 2, or merchant system 102 of FIG. 1.Aggregator system 1000 may be any suitable aggregator system, such asaggregator system 300 of FIG. 3, aggregator system 202 of FIG. 2 oraggregator system 100 of FIG. 1.

FIG. 14 is a block diagram showing detailed components of illustrativeaggregator system 1412 in accordance with some embodiments of thepresent disclosure. The aggregator system 1412 may include requestprocessing circuitry 1400, credential engine 1402, transaction storage,analytics, persistent identification storage, any other suitableprocessing circuitries, storage components, or communication components,or any combination thereof. Aggregator system 1412 may be any suitableaggregator system, such as aggregator system 300 of FIG. 3, aggregatorsystem 202 of FIG. 2 or aggregator system 100 of FIG. 1.

Credential engine 1402 may be credential engine 310 of FIG. 3, and maybe configured to determine credentials for revoking authentication of anidentified client device. In some embodiments, an authenticated clientdevice may receive credentials, and when authentication is revoked thecredentials may be invalidated. Credential engine 1402 may includemerchant rules, provider rules, data rules, match score rules, riskmanagement rules, data corroboration rules, any other suitable rules, orany combination thereof. Rules may define an event or condition, whichwhen matched may cause authentication to be revoked. In someembodiments, credential engine 1402 may determine credentials based atleast in part on these rules. Credential engine 1402 may communicatewith request processing circuitry 1400. For example, request processingcircuitry 1402 may pass rules to credential engine 1402.

Request processing circuitry 1400 may be request processing circuitry314 of FIG. 3, and may be configured with any suitable software,hardwired instructions, or both to process requests from other systemsand devices, such as client device 106 of FIG. 1 or carrier system 104of FIG. 1. For example, request processing circuitry 1400 may be atleast a portion of one or more integrated circuit processors. Requestprocessing circuitry 1400 may include an acceptor, a validator, a dataprocessor, a response deliverer, any other suitable component orprocessor, or any combination thereof. The acceptor may accept arequest, such as a request to consider a rule, and the validator, thedata processor, the response deliverer, or any combination thereof, maybe used to determine that the rule should be passed to credential engine1402. Request processing circuitry 1400 may communicate with dataprovider adapters 1406 and API gateway 1404, for example, to accept orrespond to a request.

Data provider adapters 1406 may be configured to enable communicationbetween data providers and aggregator system 1412. Data provideradapters may include carrier adapters configured to enable communicationbetween carrier systems and aggregator system 1412, and non-carrieradapters configured to enable communication between non-carrier systemsand aggregator system 1412. Non-carrier systems may include financialinstitutions, utility companies, government organizations, universities,schools, any other suitable systems, or any combination thereof.

API gateway 1404 may enable interaction and communication betweenaggregator system 1412 and other systems or devices, such as clientdevice 106 of FIG. 1. For example, a client device may make an API calldirectly to aggregator system 1412, such as an identification call orrequest for information call, and API gateway 1404 may enable such aninteraction. API gateway 1404 may include identification APIs, accountAPIs, consumer APIs, payment info APIs, match APIs, any other suitableAPIs, or any combination thereof. API gateway 1404 may communicate withclient device software development kits (SDKs), such as mobile phoneSDKs 1408. Phone SDKs 1408 may allow a client device, such as a mobilephone, to make API calls to aggregator system 1412 via API gateway 1404.Phone SDKs 1408 may include biometrics, device identificationinformation, any other suitable information, or any combination thereof.

Portals 1410 may include systems which are external to aggregator system1412, such as merchant systems, rules management systems, administrativesystems, reporting and marketing systems, any other suitable systems, orany combination thereof. In some embodiments, portals 1410 maycommunicate with aggregator system 1412, a client device, such as clientdevice 106 of FIG. 1, any other suitable system or device, or anycombination thereof.

It will be understood that the steps above are exemplary and that insome implementations, steps may be added, removed, omitted, repeated,reordered, modified in any other suitable way, or any combinationthereof.

The foregoing is merely illustrative of the principles of thisdisclosure, and various modifications may be made by those skilled inthe art without departing from the scope of this disclosure. Theabove-described embodiments are presented for purposes of illustrationand not of limitation. The present disclosure also can take many formsother than those explicitly described herein. Accordingly, it isemphasized that this disclosure is not limited to the explicitlydisclosed methods, systems, and apparatuses, but is intended to includevariations to and modifications thereof, which are within the spirit ofthe following claims.

1.-58. (canceled)
 59. A system comprising: an aggregator systemcomprising: carrier input circuitry coupled to a carrier system andconfigured to receive customer relationship management (CRM) informationand client device identification information from the carrier system;client device identification circuitry coupled to the carrier inputcircuitry and configured to identify the client device based on theclient device identification information and to cause the CRMinformation to be communicated to the client device based on the clientdevice identification information; and client device output circuitrycoupled to a client device and configured to provide the CRM informationto the client device, wherein the client device is configured to:receive a content page comprising a selectable software import; directlycommunicate with the aggregator system, using the selectable softwareimport, to receive the CRM information; and pre-populate data fields onthe content page based on the CRM information.
 60. The system of claim59, wherein the content page is a webpage.
 61. The system of claim 59,wherein the content page is provided by a merchant system.
 62. Thesystem of claim 61 further comprising authentication circuitryconfigured to authenticate a user in possession of the client device.63. The system of claim 62, wherein the authentication circuitry isfurther configured to generate two authentication keys and merchantidentification information, and to cause one of the two authenticationkeys and the merchant identification information to be communicated tothe merchant system.
 64. The system of claim 59, wherein the clientdevice is configured to use the CRM information as part of a transactionwith the merchant system.
 65. The system of claim 59, further comprisingclient device input circuitry configured to receive consent of a user,wherein the carrier input circuitry is configured to receive the CRMinformation based on the consent.
 66. A method comprising: identifying,by an aggregator system, a client device based on client deviceidentification information received from a carrier system; receiving, bythe aggregator system, customer relationship management (CRM)information from the carrier system; and outputting, by the aggregatorsystem, CRM information to the client device based on the client deviceidentification information, wherein the client device is configured to:receive a content page comprising a selectable software import; directlycommunicate with the aggregator system, using the selectable software,to receive the CRM information; and pre-populate data fields on thecontent page based on the CRM information.
 67. The method of claim 66,wherein receiving the content page comprises receiving a webpage. 68.The method of claim 66, receiving the content page comprises receivingthe content page from a merchant system.
 69. The method of claim 68further comprising authenticating, using the aggregator system, a userin possession of the client device.
 70. The method of claim 69, furthercomprising: generating, using the aggregator system, two authenticationkeys and merchant identification information, and causing one of the twoauthentication keys and the merchant identification information to becommunicated to the merchant system.
 71. The method of claim 66, whereinthe client device is configured to use the CRM information as part of atransaction with the merchant system.
 72. The method of claim 66,further comprising receiving, using the aggregator system, consent ofthe user, wherein the aggregator system is configured to receive the CRMinformation based on the consent.
 73. A method comprising: accessing,using a processor, a content page comprising a selectable import;directly communicating, using the processor, with an aggregator systemusing the selectable software import; requesting, using the processor,CRM using the direct communication with the aggregator system, whereinthe aggregator system is configured to: receive the CRM information andclient device identification information from a carrier system; andtransmit the CRM information to the client device based on the clientdevice identification information; and pre-populating data fields on thecontent page based on the CRM information received from the aggregationsystem; and displaying, using a display, the content page withpre-populated data fields.
 74. The method of claim 73, wherein accessingthe content page comprises accessing a webpage.
 75. The method of claim73, wherein accessing the content page comprises accessing the contentpage provided by a merchant system.
 76. The method of claim 75, furthercomprising using the CRM information as part of a transaction with themerchant system.
 77. The method of claim 73 wherein the aggregatorsystem is configured to authenticate a user in possession of theprocessor.
 78. The method of claim 77, further comprising transmittingconsent of the user to the aggregator system, wherein the aggregatorsystem is configured to receive the CRM information based on theconsent.